As mobile devices are becoming more complex, flexible and capable of more functionality, each mobile device evolves into an increasingly unique user specific equipment diverging from previously pre-installed functionalities. In the telecommunication world, this leads to a big change from earlier days, when mobile devices of a certain model were static with respect to both hardware and to a large extent even software.
Today, mobile devices communicate their capabilities to a wireless communication network when attaching thereto by sending its identification ID and the version number reflecting its entire software image. Further, the operator of the wireless communication network has the option, upon reception of the mobile device identification ID, to retrieve a stored version of the software installed in the mobile device into a mobile communication network operator controlled database.
FIG. 1 shows a sample management tree maintained in support of mobile device capability management.
One specification of such a management tree is specified in OMA, SyncML device management tree and description, version 1.1, February 2002.
As shown in FIG. 1, the management tree serves to specify the structure of the configuration capability present in a mobile device. The main idea is to use the management tree, which resembles, e.g., a UNIX file system. The management tree contains sub-trees called management objects MO. These management objects are composed of information required to form a specific task, e.g., they may be related to device specific information, MMS functionality or email functionality. A device information management object contains a leaf node named ‘./DevInfo/Lang’, holding information on the currently selected operative language for the mobile device.
As shown in FIG. 1, leaf nodes may be identified using a relative unified resource identifier URI, so that it is possible to read and write content of leaf nodes using standards like Synchronization Meta language SyncML. Also, such synchronization meta languages may be used to add and remove nodes in the management tree.
Further, while it is possible for the operator to update the information in the leaves of the management tree while the mobile device is attached to the mobile communication network, there exists also the possibility to change settings and to upgrade the functionality of the mobile device from other resources than the operator of the mobile communication network. Also, this may be achieved when the mobile device is not attached to the mobile communication network. Should such a situation occur, the operator would be interested in knowing what has changed in the mobile device in order to provide such information to, e.g., service applications interacting with the mobile device or third party service providers that deliver device and their content and services to the mobile device.
Here, when a new service is made available in a mobile device, this will typically lead to a new management object being installed in the management tree. In many cases, e.g., for reasons of consistency, it would be interesting for the operator of the mobile communication network to retrieve also these extensions to the management tree. It should be noted that it is not always possible for the operator to know such information in advance.
An additional problem with existing solutions is that information conveyed by the mobile device on its capabilities is usually too coarse. As outlined above, existing solutions only provide a software version number for the entire software image present in the mobile device. Typically, such information could be sent from the access network, MSC/HLR, to a service layer device management device using automatic device detection procedures, as an example.